DynamoDBのオンデマンドとプロビジョニングの料金を比較をしてみた #reinvent

DynamoDBのオンデマンドとプロビジョニングの料金を比較し、1時間にどのぐらいのリクエスト数があるとプロビジョニングよりもオンデマンドの方が利用費が高くなるのか調査しました。

AWS re:Invent 2018

#Amazon DynamoDB

#AWS

Satoshi Noto

2018.12.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

先日のAWS re:Invent 2018においてDynamoDBのオンデマンド課金が発表されました。

【アップデート】Amazon DynamoDBが従量課金で利用できるようになりました！ #reinvent

実際に自分で管理しているシステムに適用しようと思ったのですが、従来のプロビジョニングと比べて利用費が増えるのかが気になったので試算しました。その試算時に調査した結果をまとめたのが今回のブログエントリーです。

結論

まずは結論です。ReadとWriteのそれぞれの操作に関してはそれぞれプロビジョニングしているキャパシティに対して実際のリクエスト数が14.4%程度の場合にオンデマンドとプロビジョニングの金額が一致していました。具体的には100 Read or Write capacity unitを確保している場合、理論上の1時間あたりの最大リクエスト数は36万リクエストになりますが、オンデマンドを利用した場合は実際のリクエスト数が51,997リクエストを超えるとプロビジョニングよりもAWS利用費が高くなるという意味です。

14.44% = 51,997 req / 360,000 req
360,000 req = 100 Read or Write capacity unit * 60 sec * 60 min

そのため、プロビジョニングからオンデマンドに移行する際は、単純にAWS利用費だけで比較するのではなく、プロビジョニングを利用した際のキャパシティプランニングの設計/運用コストやキャパシティ不足による機会損失リスクなども踏まえた上でオンデマンドに移行するかどうか判断したほうがよさそうです。実際、私が現在管理しているシステムはキャパシティ自体は小さく相対的に運用コストの方が大きいため、今回の試算を踏まえてもオンデマンドに切り替えるつもりです。

一方でそれなりの規模でDynamoDBを利用しており、1日の中でリクエスト数に変化があってもAuto Scalingで対応できているケースであればプロビジョニングのまま利用するという判断もあるかと考えます。

前提

前述の結論は以下の前提で試算しています。

2018-12-07時点の東京リージョンの価格
1時間辺りのAWS利用費で比較
100 Read or Write capacity unitで比較

グラフ

横軸にプロビジョニングキャパシティに対する実際のリクエスト数の割合（request rate）とし、縦軸にオンデマンド（On-Demand）、プロビジョニング（Provisioned）、後は参考としてプロビジョニングで1年のリザーブドキャパシティを利用した場合（Reserved）のAWS利用費を比較しています。オンデマンドはリクエスト数課金であり、一方でプロビジョニングは1時間辺りのキャパシティに対する課金であるため、100 Read or Write capacity unitの場合の1時間の最大リクエスト数である36万リクエストを基準にオンデマンドの利用費をプロビジョニングと比較できるようにしています。そして実際のどの程度リクエストがあったかをrequest rateとして表現しています。例えば実際の1時間あたりのリクエスト数が18万リクエストであればrequest rateは50%であり、オンデマンドの利用費は18万リクエストの場合の利用費になっています。

Read capacity unitによる比較

Write capacity unitによる比較

Reservedについては前払い料金と毎時間の料金に分かれているため、前払い料金を1時間毎に支払うとした場合の実質的時間単価で比較しています。

計算式

グラフを見れば概ねオンデマンドの費用がプロビジョニングの費用を上回る位置はわかると思いますが、ここでは具体的なrquest rateを算出したいと思います。計算式としてはプロビジョニングの費用であるRead or Write capacity unitの1時間あたりの単価をオンデマンドの100万リクエストあたりの単価であるRead or Write request unitsで割ります。その際に1時間の理論上の最大リクエスト数を掛けることで、プロビジョニングのとオンデマンドの利用費が一致するrequest rateを求めています。なお、rquest rateは割合であるため以降は100ではなく1 Read or Write capacity unitを前提に計算しています。

利用費が一致するrequest rate = Read or Write capacity unit / ( Read or Write request units * 60 sec * 60 min )

料金ページの単価を入れるとReadとWriteでそれぞれ以下のようになります。

Read request rate = $0.0001484 per RCU / ( $0.2854 per million read request units * 3,600 req )
Write request rate = $0.000742 per WCU / ( $1.427 per million write request units * 3,600 req )

実際の数値は以下になります。

Read : 14.44% = $0.0001484 / ( $0.2854  * 3,600 req / 1,000,000 req )
Write : 14.44% = $0.000742 / ( $1.427 * 3,600 req / 1,000,000 req )

オンデマンドとプロビジョニングの料金体系比較

今回はReadとWriteのそれぞれの操作に関して料金を比較しましたが、その他の料金について差分があるか確認しました。

Read and write requests : 差分あり
Data storage : 差分なし
Backup and restore : 差分なし
Global tables : 差分あり
DynamoDB Accelerator (DAX) : 差分なし
DynamoDB Streams : 差分なし
Data transfer : 差分なし

ということで、今回対象にしたRead and write requests以外にGlobal tablesにおいても差分がありました。こちらについては別途機会があれば調査したいと思います。

なお、オンデマンドのリリースによりDynamoDBの料金ページがオンデマンドとプロビジョニングの2ページに分かれるようになっていました。ですが、現時点では日本語は対応していないようなので表示言語をEnglishにした上でご確認ください。

Amazon DynamoDB - Pricing

それぞれの料金ページに直接アクセスするURLは以下になります。

参考資料

最後に

いやー、事前に予想していたよりは割高でしたね。とはいえ、今後はプロビジョニングと同じリザーブドキャパシティのようなものも出てくると思いますし、本文中にもありましたようにキャパシティプランニングに必要な人件費やキャパシティ不足による機会損失なども考えると、現時点でもオンデマンドを採用したほうがよいケースはあると考えます。とりあえず私はオンデマンドに移行してDynamoDBのキャパシティプランニングについての悩み自体をなくすつもりですｗ